═══ 1. The FOSS/2 Bulletin Board System ═══ -=- The Frog Online Services System for OS/2 FOSS/2 -=- This documentation is for v1.0 -=- All included material is copyright 1991-94 by: Terje FlaarЫnning Boks 455 Sentrum N-7001 Trondheim Norway Voice: +47-94655772 BBS: +47-DOWNNOW -=- ═══ 1.1. Introduction to FOSS/2 ═══ Welcome to the wonderful world of FOSS/2, the next generation of BBS's that runs under OS/2. This system has been written with some specific traits in mind, and the author hopes he has succeded in making a simple, yet powerful BBS-system for OS/2. The system is made with growth in mind, and as such has the ability to grow with you as a SysOp. To understand the philosophy behind FOSS/2 it would be of some interest to learn how the author first came into contact with BBS's and the systems they run on! ═══ 1.2. The history behind FOSS/2 ═══ The author of FOSS/2, Terje FlaarЫnning writes: "My first meeting with modem-communications was in the summer of 1989 when I realised there were telephone connectors in the back of my PC (a old ITT XTRA from 1984). I managed to connect to a local BBS and became a frequent user there. But unfortunately my local BBS had to close down and I had to start calling long distance which was not cheap. After a short while I got the idea of starting my own BBS. My first BBS was started using the MBBS (c Mike Robertson) BBS-system and I was online from early 1990. I connected to national networks and since I got more and more conferences the MBBS system became to limited, only supporting 75 conferences. Therefore I started making my own BBS-system which is known as "The Bits & Bytes Bulletin Board System" or B&BSYS for short." Have to add something here. Late in 1993 I heard about the OS/2 patches for Borland Pascal, and this was the start of FOSS/2. B&BSYS will no longer be developed in a DOS-version, and the name has been changed because B&BSYS/2 is difficult to type a lot...... ═══ 1.3. FOSS/2 vs. other BBS-systems ═══ FOSS/2 is in many way like other BBS-systems. The main difference lies in that there is virtually no limit to how large your system may become. FOSS/2 consist of a database-structure so advanced that many of the larger and systems can only dream about matching it. This system is not just another program but it does follow all major software development rules. Simplicity is stressed throughout the system, but this does not mean that you have to sacrifice power. One of the main problems in starting a BBS is setting up the system. From there on in it is only a matter of esthetics, but the initial setup often causes problems for inexperienced SysOp's. With FOSS/2 your system is up and running in 5 minutes after you have read the SETUP information. While it is preferred that you read this file as well before entering the BBS for the first time, you can begin exploring after only a few minutes of reading! This is one of the things that makes FOSS/2 so radically different from many other compareable BBS-systems. FOSS/2 has a user friendly interface and it is almost impossible to "break" the system by using bad commands or the like. Entering a command that the system does not recognize will only give you an error message to that effect. If a script or any other part of the system has a fault in it that does force the BBS to recycle it will do just that! While some BBS-systems hang in souch a way that you will have to reboot your computer (or at least restart the program) FOSS/2 simply starts over again, delivering the user back to the login prompt. The user is not forced to call again, but is given a chance to reenter the BBS! This is a feature most BBS users will appreciate, as it saves them the bother of calling again and trying to get back in if the system is busy. ═══ 1.4. The people behind FOSS/2 ═══ The main system FOSS/2 is entirely written by Terje FlaarЫnning during late evenings the last two-three years. Thomas Stenhaug has written QWK-support and should be available where you got hold of FOSS/2. Greetings go to: Raymond L. Gwinn: Developer of the SIO drivers for OS/2 who has supported me with info about SIO and the OS/2-API concerning async-communication. Jan-Morten Havstein: Running the main Beta board for FOSS/2 who has to live with all the bugs in the prebeta versions of FOSS/2. Thomas Stenhaug: Who wrote the QWK support routines for FOSS/2, and helps me whenever I am stuck. Эyvind L. Eggen: Developer of the XBoard offline reader who made support for the FOSS/2 grab format in XBoard. The grab format has changed today, but I hope that coming versions of XBoard will support the new format. Stian Seeberg: Who wrote this and all the other DOC's available for FOSS/2 and is also running a сeta-test board (Spaceman Spiff's). Ove Christensen: Who helped Stian out with parts of the documentation and made this INF-version. My mother: Who has paid quite a few large phonebills the last couple of years. ═══ 2. Configuration of FOSS/2 ═══ When you enter your BBS (either locally or remote) you end up in the main menu shown when pressing ? + enter at the prompt. ┌─────────────────────────────────────────────────────────────────────────┐ │ v1.0 >>> MAIN MENU <<< v1.0 │ └─────────────────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────────────────┐ │ L ist users Ti me left/used X pert mode(on/off) │ └─────────────────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────────────────┐ │ B ulletin command R ead (messages) comm. T ransfer scratchpad │ │ C hat/Node command S elect a new area No de message (send) │ │ F ile transfer command U tility command Com ment to SysOp │ │ H elp O pen a external door G oodbye (logoff) │ └─────────────────────────────────────────────────────────────────────────┘ The lower part of this menu consists of the systemwide commands. These can be invoked from anywhere in the BBS. The top half is a local menu. Both systemwide and local commands is covered in the user documentation. To configure FOSS/2 you will first have to enter the SysOp menu. It is from here all systemwide changes are made. This menu is entered by typing $ (for $ysOp), and pressing ENTER. ═══ 2.1. The FOSS/2 Sysop Menu ═══ This is where you change the look and feel of your BBS! You can make changes even while users are logged on to your system, allowing you to make changes without having to shut down. This is a major improvement over several of the larger BBS-systems on the market. If one of the changes you make forces the BBS to reset because of an error the user is not logged off, but is instead given the opportunity to log on again without having to call back. No extra cost is forced upon him/her by your mistake (even though a mistake is unlikely!). ┌─────────────────────────────────────────────────────────────────────────┐ │ v1.0 >>> SYSOP MENU <<< v1.0 │ └─────────────────────────────────────────────────────────────────────────┘ ┌─────────────────────────────────────────────────────────────────────────┐ │ Co nfigure your BBS EF Edit file PA Pack area │ │ L og, Show logfile AF Add files (install) DU Delete user (kill) │ │ Us er editor DF Delete file CF Classify file │ │ Mem emory/system info D os shell/command SF Sort Files │ └─────────────────────────────────────────────────────────────────────────┘ ═══ 2.1.1. The Configure menu ═══ Configure is used to change the basics of the BBS. It is important that these settings are correct or your BBS may not work correctly. You select an area by moving the highlight up/down with the arrow-keys on your keyboard, and pressing ENTER. We will now cover these areas in detail. ┌───────────────────┐ │ Configure System │ │───────────────────│ │ General │ │ Path names │ │ File protocols │ │ Archive programs │ │ Nodes (Comms) │ │ Timed events │ │ Net-links │ │ Areas │ │ Return to BBS │ └───────────────────┘ ═══ 2.1.1.1. General ═══ This is where the general configuration of your BBS is done. The screen looks like this: Configure General Use: Esc Letters ────────────────────────────────────────────────────────────────────────── ┌────────────────────────────────────────────────────────────────────────┐ │ Board name: Test Board │ │ SysOp name (you): Sysop Sysop │ │ Location of system: Somewhere │ │ Main phone Number: (+xx) xxxx xxxx │ │ │ │ Max inactivity time: 180 seconds │ │ │ │ New users: │ │ Access level: 1 │ │ Time limit: 60 │ │ Allowed to reg: Yes │ │ │ │ │ │ │ │ │ │ Response time: 10 │ └────────────────────────────────────────────────────────────────────────┘ ═══ 2.1.1.2. Path names ═══ This is where you chose the different paths for your temporary files. The menu looks like this: Configure Path Names Use: Esc Letters Digits ────────────────────────────────────────────────────────────────────────── ┌────────────────────────────────────────────────────────────────────────┐ │ RAM disk temp dir: │ │ │ │ Scratch-pad path: │ │ D:\BBS\MAIN\SCRATCH. │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ │ CD-ROM drive letters: │ │ 1 - [ ] 2 - [ ] 3 - [ ] 4 - [ ] 5 - [ ] 6 - [ ] 7 - [ ] 8 - [ ] │ └────────────────────────────────────────────────────────────────────────┘ ═══ 2.1.1.3. File protocols ═══ This is where you configure your file protocols. The screen looks like this: Configure File Protocols Use: Esc Letters Arrows ────────────────────────────────────────────────────────────────────────── ┌────────────────────────────────────────────────────────────────────────┐ │ Letter: Z Name: ZModem OkErr: 0 Type: B_A │ │ Path: EBBS\MAIN\DSZ.COM │ │ Upload: port &p speed &s ha both rz &u │ │ Download: port &p speed &s ha both sz &l │ │ AutoRec: "**"#24 │ └────────────────────────────────────────────────────────────────────────┘ ┌──────────────────────────────────┐┌────────────────────────────────────┐ │ Z - ZModem ││ &p com port │ │ A - ZedZap ││ &s speed │ │ Y - YModem Batch ││ &l send list │ │ K - YModem Batch 1k ││ &n node number │ │ X - XModem ││ &u upload directory │ │ 1 - XModem 1k ││ &t minutes left │ │ ││ &b base addr (com3+) │ │ ││ &i irq (com3+) │ │ ││ &h com handle │ │ ││ │ └──────────────────────────────────┘└────────────────────────────────────┘ The installation process will determine if you have CE-XYZ/2 v1.00 (Copyright c 1993 Cutting Edge Computing). This is a file transfer protocol that supports Xmodem, Ymodem, Zmodem and their variants. The protocol is written specifically for OS/2 2.0 or higher. If your version of OS/2 is older then that you may either upgrade your version of OS/2 or run a DOS-based protocol. The setup procedure will also autodetect and set up HS/Link (Copyright c 1991, 1992, 1993 Samuel H. Smith) and BI-Modem (Copyright c stЖr ikke i DOC til bimodem) In case any of the protocols you want to use are not autodetected you will have to enter them manually. ═══ 2.1.1.4. Archive programs ═══ FOSS/2 supports archivers like ZIP, UNZIP, ARJ, ARC and LHA. These are all detected and configured during installation. Configure Archive programs Use: Esc Letters ────────────────────────────────────────────────────────────────────────── ┌────────────────────────────────────────────────────────────────────────┐ │ UNZIP.EXE path (used to view/unpack *.ZIP archives): │ │ D:\UTIL\UNZIP.EXE │ │ ZIP.EXE path (used to create *.ZIP archives): │ │ D:\UTIL\ZIP.EXE │ │ PKXARC.COM path (used to view/unpack *.ARC archives): │ │ PKXARC.EXE │ │ PKARC.EXE path (used to create *.ARC archives): │ │ PKARC.EXE │ │ LHA.EXE path (used to view/unpack/create *.LZH/*.LHA archives): │ │ D:\UTIL\LH.EXE │ │ ARJ.EXE path (used to view/unpack/create *.ARJ archives): │ │ D:\UTIL\MSDOS\ARJ.EXE │ │ │ │ │ └────────────────────────────────────────────────────────────────────────┘ If FOSS/2 during setup does not find or if you add one to your system after setting up your BBS, you will have to add the archiver manually. All you have to do is to specify its path. If one of the archivers are not detected, the file will be highlighted in red on a grey background. ═══ 2.1.1.5. Nodes (comms) ═══ This is where you specify the nodes on your system, and the modem settings of each node. Configure Nodes and Communications Use: Esc Arrows Letters Del ────────────────────────────────────────────────────────────────────────── ┌───────┐┌───────────────────────────────────────────────────────────────┐ │ 1 ││ Com Port: COM1 │ │ 2 ││ Init baud rate: 19200 │ │ ││ Lock baud rate: Y │ │ ││ Type of login : Wait for RING/CONNECT │ │ ││ Ring before answer: 0 │ │ ││ IO device: COM1 │ │ ││ │ │ ││ │ │ ││ Modem command strings: │ │ ││ Init: ATZ │ │ ││ Answer: ATA │ │ ││ Off hook: ATH1 │ │ ││ On hook: ATH0 │ │ ││ │ │ ││ │ └───────┘└───────────────────────────────────────────────────────────────┘ The left coloum indicates the number of the node that is being configured. You select the node by using the arrow keys (Up and down). You can have as many nodes as you wish in the registered version, the unregistered version only supports nodes 0, and 1. Node 0 is the default Local Node, and can not be configured for modem-use. The modem commands are different for each node, as each node has its own modem. These commands varey from modem to modem, and you will have to consult your modems users manual for the correct settings for your modem. However we have included some tips on what might be included (although the commands for these settings can be different from modem to modem!) in the init and init's to some popular modems in the file MODEM.DOC, which is located in the same subdirectory as this file. Init is sendt to your modem to set it in the correct state for recieving calls. All commands that need to be sendt to the modem should be present on this line. It is sendt to the modem each time FOSS/2 is started up, periodically to refresh the modem in case of difficulty, and after every caller has hung up. If the resultcode from the modem is OK, then FOSS/2 will go into a state of "Waiting for RING/CONNECT" in the case of external nodes. Answer is the answer string for your modem. Usually this is ATA, and this is what FOSS/2 defaults to. Off hook is the command string that instructs your modem to take the phone off the hook. This is usually ATH1, and this is what FOSS/2 defaults to. On hook is the command string that instructs your modem to put the phone on the hook. This is usually ATH0, and this is what FOSS/2 defaults to. ═══ 2.1.1.5.1. Type of login ═══ Type of login can be set to the following different types: Wait for RING/CONNECT Direct local login Direct login Wait for DCD ═══ 2.1.1.6. Timed events ═══ FOSS/2 is capable of running events at given times of the day/week. Her mЖ jeg ha hjelp, da jeg ikke aner hvordan det funker.... ═══ 2.1.1.7. Net-links ═══ FOSS/2 BBS's all have the capabilities to become members of a network called bNet, buildt into the system. This network consists of FOSS/2 BBS's only, and they exchange messages at given intervals. To become a member of bNet all you have to do is to register your copy of FOSS/2. You will then be given an identification address, indicating which BBS you are and where you are located, and be given a HUB that you can connect to. This HUB will take care of all the message-transfers to the other bNet BBS'es. As of this day, the bNet and Net-links part of FOSS/2 are not perfected, and as such they have not been implemented. You are therefore strongly advised to not use this feature of FOSS/2, until an upgrade is available. ═══ 2.1.1.8. Areas ═══ This is where you configure the diffrent message areas, file areas and bulletin areas. Configure Areas Use: Esc Arrows Letters Del ────────────────────────────────────────────────────────────────────────── ┌──────────────────────────────────┐┌────────────────────────────────────┐ │ Info from FrogNet ││ Area name: │ │ Mail Box (Local FrogNet) ││ Main Board │ │ Foss Support ││ Area type: Local area │ │ Main Board ││ Area code: MAIN │ │ ││ File code: MAIN │ │ ││ Door code: MAIN │ │ ││ Bull code: MAIN │ │ ││ Other: │ │ ││ # of old msg to read: 100 │ │ ││ Area flags: │ │ ││ New user autojoin │ │ ││ Message type: │ │ ││ Public messages │ │ ││ Area host: │ │ ││ Not a FrogNet area │ │ ││ │ │ ││ │ │ ││ │ │ ││ Directories -> │ │ ││ Access levels -> │ └──────────────────────────────────┘└────────────────────────────────────┘ These are the areas that are preconfigured with FOSS/2: Info from bNet Mail box B&B support Main Board You may add as many areas as you wish. Each area has a message part, a bulletin part, a file part and a door part. The message part has to be unique (or all the messages would gather in one place), but the other areas may be shared. More on this under the diffrent areas. The following things have to be configured for each new area: Area name is the name of the area in the areas list. This area list has to be made by you, the SysOp. This will be covered later in this document. Area type will usually be a Local area, as bNet areas are not fully supported as of yet. Area code is a code of up to four letters, that specifies the area as a message area. NO two areas may share the same area code! If you enter an areaname, but omit the areacode "MAIN" will be entered automatically. If this is done you WILL NOT BE ABLE TO CHANGE IT!! You may therfore have to reinstall the system. You may therfore be wise in filling this in first, and leaving the name and everything else blank until this has been taken care of. A change is to come here, making it impossible to have two areas with the same code! File code is also a code of up to four letters. Areas are allowed to share the same file code, and if you intend the files to be available to all users it may be wise to set this file code to MAIN. This is done because users need to be in the area that the file code is set for to be able to list and download the files in that area. If all files that are to be available to the users are kept in the file code MAIN, users will not need to change areas to see all files available to them. This also provides you with an easy way of shielding some users from certain files (typically adult pictures, or private files). You merely place those files in an area with a diffrent file code, and change (raise) the access level needed to enter that area! (This will be covered in Access levels.) Door code is also a code of up to four letters, and all the limitations that apply to the file codes are in effect here as well. You may wish to make certain doors available to only a limited number of users, and therefor specify a code that is different from MAIN, which is the default. Bull code is the same code of up to four letters, but it controlls the bulletins that are available in a certain area. MAIN is the default here as well, and like the File and Door areas you will only need to change the default if the bulletins should be hidden from scertain users. # of old messages to read is the limit for how many old messages a new user should read in that perticular area. This number can be set as high (or low) as you wish. However new users may not wish to read trough several hundred messages to become up to date, so set the number with care. Area flags are certain limitations, or restrictions that pertain to that perticular area. The flags are as follows: External area: used about bNet areas New user autojoin: a new user is automatically a member of this confrence No resign: users may not resign from this confrence New user autojoin; No resign: a new user automatically joins this confrence, and may not resign from it. The space can also be left blank, in which case no restrictions apply. This is the case for most local areas, and is also the default! Message type lists the type of messages that are allowed in an area. The valid choices are: Public messages: all messages are public, and can be read by all Private messages: all messages are private, and can only be read by the author of the message, the recipiant of the message and the SysOp. Public/Private messages: messages can either be public or private. Please note that the SysOp can read all messages, even those marked as private! It is up to the SysOp how much privacy is to be expected on any given BBS. Area host is used for bNet areas, and as such has not been activated yet. Access levels have to be set for any area to become active. There are two very important things to remember when setting access levels. The first is to whom you wish to give access to this perticular area. This is up to you, but you should keep in mind that all users have at least the minimum access level after loging in for the first time, and if the data in the area is sensitive (adult pictures are one type of files that should be shielded from some users) you should specify a higher access level then the minimum for that perticular area. Specifying the access level is done by entering the letter that corresponds to the level you wish to give that area. You then enter a code for what users with that access level may do. The codes for this are: R ead W rite U pload D ownload O pen All users with a higher access level will recieve the same privelages as the first level you specify. This is only natural, and FOSS/2 will fill the remaining access levels to save you the work. You may of course specify that some users will only be allowed to read messages, and perhaps write them in certain areas, and only users with a higher access level are given up/download privelages. The variations on this (and openness on your system) are up to you to decide! In addition to these five codes comes the second of the very important things to remember. That is to place an S (for SysOp) at level 15 (the letter P). This is to ensure that you are given SysOp access in this area, and as souch have all messages routed to you as well as the intended recipiant. This also grants you the option of killing messages that are deemed not appropriate by you, either morally or legally. Please remember that as the SysOp you may be held responsible for the files and (possibly) messages that appear on your system! Directories is where you speciy which directories are assigned to each area. The screen looks like this: Configure Directories Use: Esc Arrows Letters Del PgUp DgDn Directory name: Disk directory: Directory flags: The field for directory name is the name that will be listed in FOSS/2 as the directory. This name should have some connection with the files in that specific directory. You may use spaces in the name, and any alphanumerical combination. Disk directory is the directory that is on the hard drive. This does not have to have any connection to the directory name, but it MUST be exclusive. Two directory names can not share the same disk directory! Directory flags are really only used for the Upload directories, but can be used in the other directories as well. The flags that are available are: Uploaddir: the specified directory is the upload directory for that file code Show uploader: the name of the person that uploaded a file is shown along with the file description Uploaddir;Show uploader: the specified directory is the upload directory for that file code, and the name of the uploader is shown along with the file description. There must be an Upload directory for every file code! If there is not one, then an error code to the effect that one does not exist will be recorded in the Log! After configuring an area it may be wise to move the highlight up a few notches to see if the changes have taken effect, and exit the area menu before entering a new area or changing an existing one. This is to ensure that all changes have been saved to disk, in case of a disaster, like a power outage or a hanging of the computer. ═══ 2.1.1.9. Return to BBS ═══ This returns you to the BBS. You can also press Esc to exit the Co(nfigure) menu. All changes will be saved. ═══ 2.1.2. Log, Show logfile ═══ L(og) shows the usage log for the node you specify. This contains a list of new users and files that have been uploaded, and to where. It also contains a list of the different errors that have occured on the system. ═══ 2.1.3. User editor ═══ Us(er editor) is used to grant users higher access levels or unkill an unintentionally killed user. You can also grant the user higher timelimits if you so wish. It is also possible to give a user access to a specific area without giving him/her the general accesslevel that access would normally inherit. This is done through the Added Access field. The SysOp enters the area in question, and from there enters the User Editor. Added Access codes are the same as for normal usage; you can allow the user to R(ead) and W(rite) messages, U(pload) and D(ownload) files, O(pen) doors and become an A(reaOp). This last one gives the user the status of AreaOp for that perticular area. He/She may then read all messages and move them if he/she sees fit. ═══ 2.1.4. Memory/ System info ═══ The Mem(ory) function gives you a list of system information. ═══ 2.1.5. Edit File ═══ EF allows you to edit the description of a file or a list of files, depending on how you specified the file(s). The file(s) to be edited can be listed with wild-chards to increase the flexibility of the editing process. However if the SysOp plans to edit several files the CF command is superior! ═══ 2.1.6. Add Files (install) ═══ AF adds files to the filearea the SysOp specifies. The areaname is to be used, and not the directoryname! The files in the directory specified for that filearea that do not have a description will be shown to the SysOp and he/she will have to type in a description. If one is not addes the file will not be added to the filelist. The SysOp can specify a file that contains a list of the files that are to be added, and their descriptions. This allows ease of installation if the files come with a description file, or one can be made ahead of time. The default description file name is DESCRIPT.ION, which is the file used by 4DOS (4OS2) and NDOS for attaching long descriptions to files. This can be changed however to match any filename. The files that are to be added can have filenames that are up to 16 characters long (including periods!) on HPFS disks. FAT-disks have the familiar 8.3 filename restrictions. ═══ 2.1.7. Delete File ═══ DF will delete a file or several files (using wild-chards) from the filelist and the harddrive. Please note that the file is only removed from the system, and not your HD. If you want to remove the file altogether you will have to delete it manually. ═══ 2.1.8. Dos shell/ Command ═══ D(os shell) allows you to execute a DOS-command or run a file, either from within the BBS, or after you shell to the command line! ═══ 2.1.9. Pack Area ═══ PA allows you to pack an area for storage, saving all the messages in that area for later refrence. ═══ 2.1.10. Delete User (kill) ═══ DU allows you to kill a user so that he/she is removed from the register. They will have to register again if they want to get back on the system. There is no way to keep a person from logging on to your system, but you can deny them access to any and all areas of the BBS! ═══ 2.1.11. Classify File ═══ CF is a full screen file editor. It allows the SysOp to change the description of a file, move a file (with the description intact!) to a different filearea or delete files from the filelist and the harddrive. The files are tagged using the insert key, and may then be edited in the above mentioned ways. ═══ 2.1.12. Sort Files ═══ SF sorts the files in the filearea you specify. This can be time-consuming if you have a large number of files, but it is recommended that you do this often, so that the file index is updated, and the searches will go faster. Files will also be placed in alphabetical order, which makes it easier to find files even without the search tools. You are given the option to update the 4DOS (4OS2) or NDOS DESCRIPT.ION files as well. Thsi will allow the SysOp to see the descriptions when using the DIR command at the commandline if he/she has 4DOS (4OS2) or NDOS installed on the PC. ═══ 3. FOSS/2 doors ═══ FOSS/2 has the ability to run doors (external programs, games ... ) all doors are executed via the DOOR.CMD file in your FOSS/2-root directory. DOOR.CMD is called with these parameters: DOOR.CMD [Node#1] [Node#2] [ComPort] [PortSpeed] [BaseAddr] [IrqVector] [DoorName] [DoorCode] Node#1 is the number of the node, this is not prefilled. Node#2 is the number of the node, this is prefilled with zero's to a length of three characters. ComPort is current comport PortSpeed is current comport speed BaseAddr These are the base/irq data in the node setup (PS! Be sure to IrqVector set these to the same values as your fossil driver) DoorName The name or number of the door to be executed DoorCode The FOSS/2 DoorCode for current area Examples: DOOR.CMD 3 003 1 19200 02e8 3 1 MAIN DOOR.CMD 2 002 3 9600 03f8 4 TheGame GAME The DOOR.CMD file may run both OS/2 and DOS executables. ═══ 3.1. Creating the BBS-specific files ═══ As your BBS is different from every other BBS it is essencial that you create files that reflect this. There are several files that help users find their way around your system. These will have to be created by you using an ANSI drawing utility like TheDraw. The files that are most important are the lists of the different confrences, and the different file areas. In addition it may be wise to create bulletins that contain information that are of interest to your users. ═══ 3.2. Creating a list of confrences ═══ The confrence list comes up every time a user trys to Select an area but does not specify which area that should be. The file should be called AREALIST.* and should contain all confrences on your system, members only included. This because it gives the user an easily accessible way of learnign what the system has to offer. It might be a good idea to include information on the confrence, like who is in charge of it or if it is for members only (what the access level is to enter). There is a sample file that comes with FOSS/2, and contains the pre-installed areas. ═══ 3.3. Creating lists of file areas ═══ You have to create your own list of file areas that is consistent with your BBS. These files are generally ANSI files (made in an ANSI-drawing utility like TheDrawr) that FOSS/2 displays when a user asks for them (by specifying that "?" should be listed). The file should be called DIRSarea.* where "area" is the four letter file code. You will have to make one for every single file area that has a seperate file code. ═══ 3.4. Creating a list of bulletins ═══ To make a list of the bulletins you create the file areaLIST.* where "area" is the four letter Bull code. ═══ 3.4.1. Creating bulletins ═══ Bulletins generally contain information that is of interest to the user. The files are called areaxxxx.* where "area" is the name of the Bull code, and "xxxx" is the number of the bulletins starting with 0001. ═══ 4. FOSS/2 script language ═══ FOSS/2 offers a small script language to allow you to give your BBS your own look and feel. The scripts are called before or after important internal functions of FOSS/2. All scripts should be placed in the SCRIPTS sub-directory. ═══ 4.1. Scripts that need to be made ═══ There are several scripts that need to be created, to give the user a more pleasant time when logging on to your system. These scripts will be covered in detail, as to when they are executed, and hints to what they might contain. ═══ 4.2. Scripts called ═══ The following script files will be executed if they are present in the SCRIPT sub-directory: GOODBYE.* This script is executed when a user use the G(oodbye) command to exit FOSS/2 or just drop the line. The script does also function as a good-bye bulletin. LOGIN.* This script is executed just before the user gets his command prompt (after display of users stats). PREDOWN.* These scripts are executed before and after downloads, the scripts POSTDOWN.* can be used to control download rules and so on The scripts also function as file transfer bulletins, but only with normal file transfers. PREUP.* Same as the *DOWN.* scripts but for uploads. POSTUP.* PREOPEN.* Same as the *DOWN.* scripts but for door usage. Be aware of that POSTOPEN.* these scripts function in all areas. PREREG.* These scripts are executed before and after a new users register. POSTREG.* U-[com].* Called from Utility menu if unknown command. B-[com].* Called from Bulletin menu if unknown command. C-[com].* Called from Chat/Node menu if unknown command. $-[com].* Called from $ysOp menu if unknown command. F-[com].* Called from File menu if unknown command. R-[com].* Called from Read menu if unknown command. G-[com].* Called from all menus if none of the above exits and unknown command. The astrix is a language key or can be left blank for multilangual scripts. The language key for Norwegian scripts is *.N, and for English the language key is *.E. ═══ 4.3. Script variables ═══ In scripts you have several variables for you usage, these are: &[1-9] User variables. &ac Current area code. &ad Current area door-code. &af Current area file-code. &an Current area name. &td Current date. &th Current time (hour). &tm Current time (minute). &tu Time used so far this logon, in minutes. &u - - - USER RECORD VARIABLES &ua1 First line of address &ua2 Second line of address &ual Accesslevel &uc City &ud# Number of downloads &udk KB downloaded &uf First name &ul Last name &umw Messages written &umr Messages read (Not counted in FOSS/2 yet) &un Name &uph Home phone &upw Work phone &uu# Number of uploads &uuk KB uploaded &uta Time allowed each 24 hours &utl Time left when logging on (&utl - &tu = time left) &utt Time totally used &$ - - - SYSTEM DATA VARIABLES &$h Systems current com-handle in hex. &$m Current menu level: M(ain), R(ead), F(ile) and so on. &$v Display current FOSS/2 version. &! - - - DISPLAY SETUP/MANIPULATION PROCEDURES &!l Do linefeeds until cursor resides at the bottom screen line. &!m Do more prompt. &!w Wait for keypress before continue. These variables can be used anywhere in your scripts. ═══ 4.4. Script commands ═══ A script language without commands is nothing so here they come! These commands are available for script programming: @+ [uservar] [firstnumber] [secondnumber] "" @- [uservar] [firstnumber] [secondnumber] "" @* [uservar] [firstnumber] [secondnumber] "" @/ [uservar] [firstnumber] [secondnumber] "" @assign [uservar] [textstring] """"""" Assigns a textstring to a uservariable "@assign 1 This is a string" @command [commandline] """""""" Execute standard FOSS/2 command from a script. "@command Read Enter Sysop" @delfile [filename] {filename} {filename} ... """""""" Delete one or more files on the harddisk. "@delfile FOSS/2.EXE" (not try this) @exit """"" End script execution and return to FOSS/2. "@exit" @file [filename] """"" Open a file for output, the file is created if it do not exist. "@file scripts\tempfile.lst" @goto [label] """"" Go to @[label]. "@goto firstlabel" @if [firststring] [secondstring] [label] """ Compare two strings, if equal then goto [label] of not then continue. "@if String String ThisLabel" @if [firstnumber] [<|=|>] [secondnumber] [label] """ Compare two numbers, if condition is TRUE then goto [label] if not then continue. "@if 1 = 2 OneLabel" @iffile [filename] [label] """"""" If file [filename] exist the goto [label] if not then continue. "@iffile scripts\tempfile.lst" @input [uservar] [prompt] """""" Let the user input a text string into the given uservar. "@input 1 Type a command @log [text] """" Write a line to node log file. If [text] starts with "$" the text goes to the .SYS log instead of the normal node log. "@log $User has failed" @mod [uservar] [firstnumber] [secondnumber] """" @run [program] [parameters] """" Runs an external program, this must be a OS/2-text mode executable. "@run FOSS.exe" @rundos [program] [parameters] """"""" Same as @run, but this loads a new command interpreter before running your program, this may run .CMD files and DOS executables as well as OS/2 executables. "@rundos test.cmd" @select [words] [prompt] """"""" Wait for user input. "@select YesNo Delete message?" (this go to first @Y or @N after present line) @set [sysvar] [value] """" Set a specific system variable to given value. [sysvar] [value] menu M,R,B,F,C,$,U @show [filename] """"" Type a textfile. "@show scripts\tempfile.lst" @write [text] """""" Write a text to open file, no CRLF included. "@write This is a text" @writeln [text] """""""" Write a text to open file, CRLF included. "@writeln This is a text line" ═══ 5. Technical info about FOSS/2 ═══ ═══ 5.1. System requriements ═══ This program runs under OS/2, and as a result you are forced to live with it's demands on your hardware. We feel that for any type of performance a 386dx with 8 MB of RAM is the minimum, although OS/2 (and therefore FOSS/2) will run on any 386 with over 6MB of RAM. In addition you will of course need a modem and a telephone line! The unregistered version of FOSS/2 has one feature that is limited. You are limited to 20 users on the system. This means that the 21. person who logs on to your system will overwrite the 20. person. This should allow you to evaluate the system well, while still maintaining an incentive to register your copy. Upon registration you will recieve a KEY-file, a bNet node address, and a HUB to connect to, allowing you to exchange messages with the other FOSS/2 BBS'es. ═══ 5.2. File structures ═══ The structures of all system files may be obtained directly from me. Hva skal jeg si om API'en?!? Skal den stЖ her, eller noe annet sted? Kan du gi meg noe Ж skrive om den pЖ norsk, sЖ oversetter jeg simpelt det til engelsk.....eller ihvertfall en skikkelig forklaring pЖ hva den API'en er og hva den gjor!?!? ═══ 6. About the documentation ═══ Please note that all documentation are under writing, so all features may not be covered in this release. We will, however, have proper documentation ready when FOSS/2 ships. You should also read the BITS0001 bulletin which may include changes to the system not covered here. The documentation will be organized in the following manner: FOSS/2 User Guide FOSS/2 Sysop Guide (this INF) FOSS/2 Developers Guide and Technical Reference FOSS/2 Reference Setup Guide This documentation will also be available in ASCII-files for those of you who prefer this. If any of you have any comments to the documentation or the INF-version, please post us a message. Email adresses: ove.christensen@bb.fidonet.bbs.no stian.seeberg@bb.fidonet.bbs.no Stian and Ove ═══ ═══ The boards name you will have to enter yourself. It should match the name you have chosen for your BBS. ═══ ═══ Your name is autodetected, however if there are several people who have SysOp access any of these can be entered in this field. A user without SysOp axess will not be allowed entered in this field however. ═══ ═══ Here you can enter the geographical location of your system. ═══ ═══ Enter your systems main phone number. Eller menes det VOICE telefonnummer til sysop? ═══ ═══ Max inactivity time is the number of seconds a user may remain online without being ejected from the BBS. This is useful if the user falls asleep while online, or simply forgets that he/she is online. It prevents not only that your system remains busy, but saves the user from a rather large phonebill! ═══ ═══ Access level is the level of access given new users. This will determine what areas of your system they will be allowed to enter. More about the different areas in the Areas submenu. ═══ ═══ Time limit is the number of minutes a new user is given online. ═══ ═══ This function determines whether a new user should be able to register or not. For most commercial BBS's this option should be set to yes. However, if you only use your BBS just for providing drivers and similar things, this option could be set to no. In such cases you should consider not to allow users to upload files to the BBS. ═══ ═══ Response time is how fast the system reacts to input from the user. The default value of 10 should be acceptable for most systems. ═══ ═══ In OS/2, you can set up a RAM disk using the VDISK.SYS utility. Type "help vdisk" at our OS/2 command prompt for reference. This should only be done if you have plenty of RAM on your system, othervise system performance will suffer badly. Your RAM disk should be at least 2 Mb for a single-node system. A multi-node BBS requires more. If you choose not to have a RAM disk then leave the field empty. ═══ ═══ The scratch-pad should be placed on your fastest hard drive, or preferably on a RAM disk. You should monitor the size of the scratch-pad and set up a RAM-disk that is big enough. You should also consider changing the name of the scratch-pad to reflect your system. If you change the name of the scratch-pad remember to omit the extention! This will be added later by FOSS/2 to reflect the node that the messages were dumped to. ═══ ═══ If your system has any CD-ROM drives, and you wish to make the files on it (them) available to the users, then place the drive letter in the chechbox(es) that match your system. Please note that entering a drive letter does not give the users on your BBS access to all the files on that CD-ROM. Only files that are added to your system (by you) will be available! ═══ ═══ Letter is the letter of the alphabet that represents this protocol in the list of available protocols that are presented to the user in the Pr(otocol) part of the Ut(ilities) menu. ═══ ═══ Name is the name of the protocol. This is also shown to the user in the Pr(otocol) part of the Ut(ilities) menu. ═══ ═══ OkErr ═══ ═══ Type has three possible switches; B, B and A. These stand for Batch, Bi-directional and Autodetect. Batch protocols have the ability to send and recieve filenames, and several files at a time. Bi-directional protocols send files both ways at the same time. In other words the user may Upload and Download at the same time. Autodetect specifies whether or not the protocol is capable of detecting whether a file is being Uploaded, and automaticaly starting the upload procedeure on the BBS's side of the connection. ═══ ═══ Path is the path to the file, including the filename and extention. ═══ ═══ Upload is the command string sendt to the program to start the upload process. ═══ ═══ Download is the command string sendt to the program to start the download process. ═══ ═══ AutoRec is the string the program should look for when autodetecting an upload (if the protocol supports autodetection). ═══ ═══ Com Port specifies which serial port the modem for this particular node is connected to. ═══ ═══ Init baud rate is the speed that the system will communicate with the modem at. For the best settings for your modem, consult your modem manual. ═══ ═══ Lock baud rate can be set to one of the following: Y(es) - Baudrate is locked N(o) - Baudrate is not locked Determines wheter or not the rate of data transfer between the computer and the modem should be locked, or be dictated by the connect baud rate. It is recommended that you use a locked baud rate, setting this option to Y(es). ═══ ═══ Rings before answer tells the BBS how many rings it should wait until it answers the call. This defaults to 0, but can be set to any number. ═══ ═══ IO Device is the device that provides the data Input and Output. This is the same as the COM port. ═══ ═══ The BBS waits until it recives a RING signal from the modem,sends the answer string (covered below) and waits until it recieves a CONNECT message from the modem. The user is then allowed to log in. ═══ ═══ This type is for purely local nodes (like node 0). This login type allows for more than one local node, which can be convenient if you for instance are running your BBS on a network. ═══ ═══ For use if another program like a frontdoor is the initial recipient of the call, forwarding it to FOSS/2 once a connection has been estabelished. ═══ ═══ Used for logins directly from another computer without the use of a modem. A 0-Modem cable is used to connect the computers.